Before you write to me with suggestions for the next version of Bolo, please read these frequently asked questions files, and read the "Bolo.futureplans" file to see if your suggestion is already on the list.
• "Why are there so many FAQs for Bolo?"
I guess there are a lot of people using Bolo a lot of different ways.
"Bolo.GeneralFAQ" contains general questions about Bolo.
"Bolo.GameFAQ" contains questions about gameplay issues in Bolo.
"Bolo.Maps&BrainsFAQ" contains some hints and advice for people creating maps and for people writing Brains.
"rec.games.bolo FAQ" (in two parts) contains questions compiled from the Internet News Group. I did not write it, but I include it here because it has some useful information, and provides an alternative perspective on the game.
• "If I pay the shareware fee, what do I get?"
You get exactly what you get when you buy a game in a shop, namely, the game. Just like in shops, you can take the game without paying for it if you want, but the people who run shops are reputed to react rather badly if they see you doing this :-)
• "What's this thing in the About Box about Developer Conferences?"
It was a request to Apple to send me a free pass to their World Wide Developer Conference, which is held every May. Being a Mac programmer can be pretty disheartening, especially when you see the size of the PC market and the amount of money that games like Doom can make. Going to the Developer Conference two years ago and seeing the neat new things that Apple was working on really renewed my enthusiasm for programming on the Mac. Apple's evangelists have a number of complimentary WWDC passes for developers they want to encourage, and I'd hoped that this year they would decide that Bolo deserved encouragement. Well, they didn't. That's not to say that there aren't great people at Apple. First place for outstanding efforts in support of Bolo goes to Brent Pease of ATG Graphics, with Craig Fryar, Bill Gibson, Dennis Hescox and Brian Wilson as runners up, and numerous other strong strong contenders. (To be fair, all but one of those people have since left Apple.)
• "Why doesn't Bolo have a pause mode, like for when I have to answer the telephone?"
There are other human beings out there on the net playing at the same time. What happens to them? I know they make time stand still all the time on Star Trek, but I haven't figured out how to do it yet. If you have to leave your computer, put it onto autopilot. Select some defensive settings, and it will stay where it is and try to take care of itself until you return.
• "Bolo is almost unplayable on my slow Mac Plus."
The Macintosh Sound Manager does a lot of work to make those sound effects on older Macs which lack fancy sound hardware. On A Classic 8MHz 68000 Mac, half the CPU time can be spent doing sound, so you can double the performance of Bolo by turning sound off. Alternatively, upgrade to Sound Manager 3.0 (included in System 7.5) which is a lot more efficient.
• "Why does Bolo make strange squawking sounds occasionally?"
Bolo is a heavily network oriented program. In a ten player game 90% of what Bolo is doing is determined by the packets sent by the other 9 players, and only 10% by what keys you are pressing on the keyboard. Network protocols differ from normal algorithmic programs, in the sense that instead of the program telling the computer what to do and when to do it, it is the other way around. The computer tells the program what to do and when to do it, in the form of an "interrupt" every time a network packet arrives. This is how Bolo works. There are only two components of the Macintosh System software that don't work when called from interrupt routines, the Memory Manager, which is sort of understandable, and the Sound Manager, which isn't. I have talked to Jim Reekes about this in person several times and he is adamant that he sees no reason for the Sound Manager to work from interrupts at all, and he most definitely has no plans to ever support it. Jim Reekes has done a pretty excellent job on Sound Manager 3.0 in all other respects, so Apple is not likely to replace him. It seems that Bolo is stuck with the strange squawking sounds, at least until there's a major change in the System Software.
• "Why doesn't Bolo accept that if we put sound on 0, we want no sound?"
It's nothing to do with me. Bolo just makes Apple Sound Manager calls. Why doesn't the Apple Sound Manager accept that if we put sound on 0, we want 0 sound? I don't know. That's why Bolo has a menu option to turn sound off, which is probably better -- just because you want no sound from Bolo doesn't *necessarily* mean that you don't want any other sound from your computer, so I offer the added flexibility of an application-specific switch for Bolo.
• "I turn on 'Background Sound' but there is no music."
Background sound does not mean music, it means Bolo continues to make sounds when you put it in the background to work with some other application. RTBH! (Read the Balloon Help.)
• "How do I play Bolo on my own against computer controlled enemies?"
Bolo is not designed to work this way, but you can make it work. You need to run several copies of Bolo, and have them controlled by "Brains" for you to play against. They can run on different Macs, or all on the same Mac, if it is fast enough (ie not a Mac Plus or SE). In either case, you need to have AppleTalk enabled (in the Chooser) for the different copies of Bolo to communicate with each other, even if they are colocated on the same Mac. Make a folder called "Opponents" and put a copy of Bolo and the "Brains" folder into it. Since Brains don't need to have digitised sound effects, you don't need to copy the "Bolo Sounds" file, and you can reduce Bolo's memory allocation to 800K in its "Get Info" box. Now, duplicate the Bolo application file a few times, and call them "Bolo 1", "Bolo 2", "Bolo 3", etc. Run each copy of the program in turn, joining them into the same AppleTalk game, and switching them all to Brain control. Now go back to your original copy of Bolo and join into the game.
• "Why doesn't the auto-slowdown option with with cyborg Brains?"
Cyborg Brains do their own keyboard processing, and ignore all the settings in Bolo's key setup dialog. I'm planning to add facilities to Bolo to allow cyborgs to be better integrated, but for now that's just the way it is.
• "What is the Frame Rate menu for?"
If you are running some other program(s) in the background while you play Bolo, setting Bolo to a lower frame rate will allow the background program(s) more CPU time. One example might be when you are running other copies of Bolo in the background, as described above. If you set your frame rate to 60 frames per second then the Brains won't get enough time to think, and they will not be very challenging opponents.
• "What's the point of the joystick option?"
For playing Bolo with the standard overhead view it's not very helpful, but imagine if there were a 3D 'Doom-style' version of Bolo under development... :-)
• "Why don't you generate a new random map for each new game?"
There are several hundred maps available from various Bolo enthusiasts, so you have a wide choice. Peter Lewis has also written a pretty good random map generator which outputs a different random Bolo map file each time you run it, but I still prefer the maps made with human creativity to random ones. If you think you can write a better algorithm to generate plausible looking interesting maps, then why not write it? You know what the different terrain types are, you know the map file format, and I've even provided sample C to read and write the files, so the framework is all there for you.
• "Why don't you produce a map editor so that I can create my own maps?"
I was going to, but several other people got impatient and wrote their own. Check out anonymous ftp on Sumex-aim.Stanford.EDU (in "info-mac/game/bolo").
• "Some of the map editors allow you to set the ownership number of bases, but when Bolo saves a map itself, ownership is ignored and all of the bases revert to neutral."
Setting the ownership number for a base falls in the "cute but useless" category. You can make novelty maps where everyone starts with one base and one pillbox, but when you join the game there is no guarantee that you will get the same player number as before, so it is all a bit pointless. 'BGAM' game files will be the solution to this problem.
• "Why don't you add xyz feature?"
One of the main goals in writing Bolo was to try to give it one of the properties that Chess, Othello, and other good board games have -- the "a moment to learn and a lifetime to master" characteristic that gives them lasting interest. The aim is that there are a few simple 'actions' that you can perform in the game, but that they are flexible enough to let you carry out your complex strategies. That's why there is only one kind of tank, one kind of armour, and one kind of bullet. For me to add another major feature, it must add at least as much interest to the game as any of the features that are already there.
• "Why don't you add some feature [that Bolo already has]?"
This is one of the most annoying kinds of question. Here's common one: "I hate having to click the close box to put away the message window, why don't you:
a. Make some key, like say "Escape", dismiss the window?
b. Use the standard Macintosh convention of Command-W to close the window?
c. Use Command-M to hide the window, since Command-M is what you do to show it?
d. Just let the user click anywhere in the game window to bring it to the front?
JUST TRY IT BEFORE YOU WASTE MY TIME WITH E-MAIL. THEY *ALL* WORK ALREADY.
• "Why doesn't Bolo have a 'panic' button to hide all the windows?"
Duh! (See above) It does. Command-H hides all the windows. Besides, System 7 has its own built-in 'panic' command -- option click in any other application's window (or on the desktop) to instantly switch to that application and hide all the windows of the current one.
• "I really like Bolo except for the fact that I need to have friends to play it with. Why don't you make a single player version?"
Two answers:
1. If you want a single player game, there are thousands already. Play one of those instead. I'm writing a multi-player game.
2. As described above in "How do I play Bolo on my own?", run Brain-controlled copies of Bolo in the background, and play against them.
If you want to try writing your own Artificial Intelligence routines to drive enemy tanks, sample source code is provided. If it turns out to be popular, we could have a new kind of Bolo Turing Test, where you have to play against various opponents and decide whether they are human or not. (Anyone remember the old 'Core War' tournaments? It would be fun to see Bolo become the battle ground for similar programming competitions).
• "I am going to write a totally awesome network game for the Mac. Please tell me how to do it." (Yes, I really do get this question quite frequently.)
There is no magic spell; no secret to tell. I use simple point-to-point AppleTalk DDP packets. Bolo does not use broadcast DDP packets like most games, because that doesn't work across multiple networks. Bolo does not use ATP, or ADSP, because these offer extra features and reliability that Bolo doesn't need. So-called "reliable" protocols don't work by having a magic genie, they work by sending extra packets and waiting for acknowledgements. The increased reliability is always a trade-off against extra delay and lower throughput. I can write code to deal with unreliability. I have not yet managed to write a time-travel routine to deal with packets being delivered late because a "reliable" protocol delayed them. Bolo uses NBP to locate other players, but that is of course only at startup time, not during the game itself. The game communication works by having all the machines forward packets from one to the next in turn so that they form a logical ring with packets going all the way round hop-by-hop until they get back to the start. Bolo works equally well with UDP/IP and could work with any other datagram protocol. Point-to-point datagrams are not the best way to do everything, but until there is better support for multicast, there is no good solution to this problem. If you want more information, the Cambridge University Computer Science Library has my undergraduate degree project report "An Experiment in Real Time Networking" which describes everything in great detail. The Microsoft Word file is also available by ftp from Bolo.Stanford.EDU. Hayden Books are also publishing a book this summer called "Tricks of the Mac Game Programming Gurus" which is full of amazingly useful information. You can find out more about the book at http://www.mcp.com/hayden/mac_game-gurus/index.html
• "Can I have source code?"
Sorry, I'm not giving out Bolo source code yet, and perhaps not ever if I decide to sell it commercially. Besides, until I work out the security issues, it would make it too easy for people to compile rogue versions of Bolo with indestructible tanks and unlimited firepower. Is that what you want to meet coming out of the forest on a dark night? If you want sample code showing how to use ATP, NBP, etc. check out Sumex-Aim or the mirrors. You can also get an excellent collection of sample code on the Apprentice CD from Celestin (Telephone USA [+1] 206 385 3767, or e-mail celestin@pt.olympus.net, or point your Web Browser at http://www.celestin.com/products/apprentice/index.html).
• "What is the "BBC ROM file" 'ROMd' resource? Did you secretly implement a 6502/BBC Micro Emulator just to play this game ;-)"
No, Bolo was originally written for the BBC micro, and then ported to the Mac. The BBC Micro only had a 2MHz 6502 processor and 32K RAM. 20K of that was screen memory, and the operating system consumed another 4K itself, so that only left 8K for Bolo. Even written entirely in 6502 assembly code, Bolo turned out to be just a little too ambitious to fit into 8K, so I had to find some way to get more memory. What I did was to replace the BBC Micro's BASIC ROM chip with a 16K EPROM of my own into which I had programmed all of the graphics character data. Bolo on the Mac still uses exactly the same graphics character data as the original BBC Micro game, which is why the EPROM data is included as a resource. Some day I might decide to improve the graphics on the Mac, but it there are many other higher priorities.
• "I think Bolo is great, but I'd like to redo the graphics for it."
You may think that you can just draw new pictures in MacPaint and I all have to do is paste them into Bolo to make it work, but it would take a lot of programming effort, and my priority is networking, not graphics. Many many people have offered to do this, but so far only map editor authors are in any position to claim they have also written the code to display graphics on the screen. It's not easy, especially when you need it to be fast enough for real-time interactive use.
• "My company wants to sell Bolo commercially. How about it?"
Commercialization would kill Bolo. We are at the dawn of an era. In ten years time computers, displays and networks will have evolved to the point where multi-user interactive virtual reality simulations will reach a quality which is unimaginable today. I hope that in retrospect Bolo will be regarded as as an ambitious first attempt at such a networked multi-user synthetic world, as useful research which taught valuable lessons. An attempt to bleed money out of it at this early stage would destroy it. Bolo will be freely distributed for the Macintosh because the Mac has ubiquitous networking. However, the big markets will always be in the Nintendo/Sega/IBM PC class machines, so if there is to be any commercialization, that is where it will be. In the near future, I think we can expect to see these class of machines evolve to the point where networking becomes a standard built-in feature. The Macintosh will make Bolo famous, and if you want to buy the source code to port it to one of these other machines, then give me a call in a couple of years' time, and we can talk about it.
• "What about all these other versions of Bolo from other people I hear about?"
A number of other people have worked on implementating Bolo for DOS and for Windows.
The reason that I have not offered my assistance is that I don't have the time to give a lot of help, and a lot of help is what would be required to make sure that the networking code operated properly. The networking code in Bolo is very complicated -- it is about half of the entire program. If I were to publish the network communication protocol then my worry is that the other implementations would work just well enough to connect to a game most of the time, but not well enough to keep the game going without destroying it.
The other factor is that I am still changing the Bolo communication protocol, so anything I published would be out of date with the next release.
When the protocol is stable and finalized, then I might think about interfacing with other compatible implementations.
• "Why is it called Bolo?"
Bolo is the Hindi word for communication. Bolo is about computers communicating on the network, and more importantly about humans communicating with each other, as they argue, negotiate, form alliances, agree stategies,. etc.
• "When are you going to update Bolo to use Open Transport?"
OpenTpt (pronounced "open teapot", I think) is not released yet. I'm not a registered Apple developer, and I didn't get to go to the Developer Conference. I don't get any special treatment from Apple, so until the OpenTpt developer kit is made public there's not much I can do. OpenTpt offers one significant new feature -- multicast -- but before I can take advantage of that I will have to rewrite all the Bolo networking code to use the new OpenTpt programming interfaces, which will be a lot of work.
• "When will Bolo work with ARA?"
Unlike SLIP or PPP, ARA changes the network addresses inside the packets. It does this for ATP, ADSP, NBP, and other protocols that it knows about, but not for the Bolo protocol. I'm hoping that OpenTpt will provide an easy way for me to make Bolo work with ARA.
• "When are you going to write a native PowerPC version of Bolo?"
Not soon. Bolo is about 85% interrupt routine and about 15% forground code to draw the graphics. Since the System software doesn't yet support native interrupt routines (only emulated ones!) it's not just a case of "recompile it with CodeWarrior" as many people quite naturally assume. If Bolo seems slow or jerky on your PowerMac check what frame-rate you have Bolo set to, and make sure you're not running too many other programs in the background. I've played Bolo on a basic PowerMac 6100/60, and it seemed fine to me.
• "Why did it take you so long to bring out version 0.99.5 of Bolo?"
A variety of reasons. Bolo 0.99.2 was a big mess internally, and it needed a lot of tidying up before I could make any more progress on it. I also had lots of other demands on my time, and Mac programming has just got a lot harder than it used to be. Back in 1984 people expected a Mac program to have windows, a menu bar and cut-and-paste. By the time System 6 came out, programs were expected to support colour, multiple monitors, MultiFinder, and the Sound Manager, all of which, I'm pleased to say, Bolo does. Since System 7, the programming burden has gone way up. To write a respectable program on the Mac these days a programmer has to learn about Balloon Help, Apple Events, Movable Modal Dialogs, Program Linking (PPC Toolbox), Publish and Subscribe, DeferUserFn for Virtual Memory Compatibility, QuickTime, WorldScript, Drag-and-drop, PowerTalk Mail, AppleScript, ColorSync, Drag Manager, Thread Manager, Macintosh Easy Open, Apple Guide and GuickDraw GX. People send me mail all the time asking when Bolo is going to be PowerMac native. Pretty soon there's going to be QuickDraw 3D, OpenTpt, Copeland, and who knows what else to support too. I don't think I can keep up.
• "What happened to Bolo versions 0.99.3 and 0.99.4?"
They were versions written to support some contract work I did for the US Army Research Institute in Alexandria which uses Bolo for team training experiments. They set the players tasks, and sometimes limit the controls of the tanks, so one player can only build, one can only shoot, and one can only lay mines. They use the map overview (in omniscient mode) to record the action over the whole island on a video recorder, and they use the game logging to record a blow-by-blow account of exactly what happened for post-portem analysis. The Log Reader program is owned by ARI since they paid for it.
• "What's this omniscient mode?"
It lets you see the entire island, regardless of where your tank and pillboxes are. It is not in the standard version of Bolo because I haven't figured out how to put it in without opening the door to outrageous cheating. I'm thinking about it.
• "Hey, I love Bolo, but when are you going to write it for the IBM PC?"
As soon as I finish my PhD.
• "I thought you said "never" in the 0.99.2 ReadMe file?"
That was written in 1993. Things change. Back then DOS and Windows were a mess, PCs didn't come with networking built-in, sound was optional, and there were a dozen different kinds of graphics cards to support. Now it's 1995. Networking and high quality sound is becoming standard on PCs. Windows 95 promises a single uniform TCP/IP programming interface, a single uniform graphics programming interface, and a cleaner programming environment in general. With a little encouragement and support from Apple I might have stayed with the Mac, but it's time I stopped deluding myself. Apple isn't a charity, and Apple is not going to support me just because I support the Mac. Business is business, and the bottom line is all that counts. Apple keeps saying you should judge a computer by the market share it has, not by the quality of the computer, the software or the company that makes it. They may be right.
